Click Here!
home account info subscribe login search My ITKnowledge FAQ/help site map contact us


 
Brief Full
 Advanced
      Search
 Search Tips
To access the contents, click the chapter and section titles.

Oracle Performance Tuning and Optimization
(Publisher: Macmillan Computer Publishing)
Author(s): Edward Whalen
ISBN: 067230886x
Publication Date: 04/01/96

Bookmark It

Search this book:
 
Previous Table of Contents Next


These qualities went into the first benchmark developed by the TPC and are still present in all the benchmarks developed today. In the years since the TPC was originally founded, it has grown from the original 8 members to over 40 of the leading computer industry companies. As of January 1, 1996, the TPC membership consists of the following companies:

Amdahl Mitsubishi Electric Corp.
AT&T Motorola
Australian Dept. Admin. Svc. NEC Systems Laboratory
Bull Mikkei Business Publications
Compaq Computers Novell
Convex Computer Corp. OKI Electric Industry
Cray Research Olivetti S.P.A
Data General Corp. Oracle Corp.
Digital Equipment Corp. Pyramid Technology
EDS Samsung
EMC Corp. SCO
Encore Computer Corp. Sequent Computer
Fujitsu/ICL Siemens Nixdorf Information
Hewlett-Packard Silicon Graphics
Hitachi SW Software AG
IBM Corp. Sony Corp.
IDEAS International Stratus Computer
Informix Software Sun Microsystems
Intel Corp. Sybase
Intergraph Tandem Computers
ITOM International Toshiba Corp.
Microsoft Corp. Tricord Systems Inc.
Unisys Corp.

The TPC is made up of the general membership, in which each member company has one vote. From the general membership, a steering committee and Technical Advisory Board are elected.

The steering committee is responsible for setting the overall direction of the council and providing recommendations to the council. It is also charged with the administrative and support activities of the council.

The Technical Advisory Board (TAB) investigates issues involving compliance to TPC specifications and makes recommendations to the council on these matters. The TAB is also responsible for recommending changes to the benchmark specifications for clarity.

Any change in a specification or compliance issue decided by the TAB must be brought to the general council for decision. Every issue in the TPC requires a 2/3 majority for passage. The steering committee and TAB are merely filters; all significant decisions are made by the general council.

The TPC has gone from the original Credit/Debit benchmark to seven benchmarks (by mid-1996). These benchmarks include Decision Support, Client/Server, and Enterprise benchmarks. Each of these benchmark specifications is discussed in this chapter.

TPC Rules and Regulations

To publish a TPC benchmark result, the sponsoring company is required to follow a set of rules and regulations. These rules are designed to provide a fair playing field for all participants. Here are some of the significant rules:

  Only results that have been published can be advertised as TPC results.
  Once results are submitted to the TPC, there is a 60-day window in which the results can be challenged by other members of the council on the grounds that the benchmark does not comply with the specification. If the challenge is upheld, the results must be removed.
  Estimated results cannot be advertised.
  Comparisons cannot be made between different major releases of the TPC specifications (for example, you cannot compare TPC-C 3.x results with TPC-C 2.x results).
  Since January 1, 1994, all TPC benchmarks must be independently audited by a certified TPC auditor.
  Full disclosure reports must be submitted with all TPC results.
  Published results must include all primary metrics. For most TPC benchmarks, this means both performance rates and price/performance but may include more.
  TPC benchmarks support ACID properties (Atomicity, Consistency, Isolation, and Durability, as described in the following section).
  The availability date of nonshipping components must be disclosed.

These rules have been approved by the council and must be followed by all members. If these rules are violated, the council has steps it can take. It is very rare that any of the rules are violated—and then usually by mistake.

ACID Properties

The ACID (Atomicity, Consistency, Isolation, Durability) properties are designed to show that the system operates in a manner consistent with systems deployed in user installations. ACID properties are the main regulating factor that keeps benchmarks from being published in a mode inconsistent with typical operation. Consider a case in which the system might run faster if logging were disabled. Although the performance increases, the test is inconsistent with typical operation because disabling logging prohibits any recovery in the event of a system failure.

The ACID properties are as follows:

  Atomicity. The system must guarantee that all operations are atomic. This means that a transaction must complete all individual operations on the data or guarantee that partial operations have no effect on the data.
  Consistency. Consistency requires that any execution of a transaction leaves the database in a consistent state, assuming that the database is in a consistent state to begin with. This property guarantees that the books are balanced. An example of this property in the TPC-B benchmark (described later in this chapter) requires that the sum of all the account balances for a teller must match the teller balance, and that the sum of all teller balances in a branch must match the branch balance.
  Isolation. Isolation requires that operations of concurrent transactions must yield results indistinguishable from the results obtained when you execute the transactions serially in some order. This property is commonly known as serializability. Furthermore, this property must be guaranteed with respect to arbitrary transactions as well as other benchmark transactions. Repeated reads of the same records within any committed transactions must also be guaranteed to return identical data when run concurrently with any mix of arbitrary transactions.
  Durability. The durability property requires that the system must demonstrate that all transactions returned as completed have in fact been committed in spite of any system failure that may have occurred. To demonstrate this, a system crash test must be run and it must be shown that no completed transactions have been lost.

These properties guarantee the integrity of the system and add credibility to the benchmark results. Although these tests are quite time consuming, they are required for a certified result.

Requirements like these give a lot of credibility to the TPC and to the vendors that run the tests. To pass these ACID tests, the database platform must prove it is a stable, robust system capable of handling your business.


Previous Table of Contents Next


Products |  Contact Us |  About Us |  Privacy  |  Ad Info  |  Home

Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc.
All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited.